home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 345 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  6.4 KB
  1. Subject: Wholemeal Digestive [avg][7 Jun 94]
  2. Date: Tue, 7 Jun 1994 11:44:41 +0200 (MDT)
  3. From: Annius.Groenink@cwi.nl (Annius Groenink)
  4. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  5.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  6.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11. Here are my fortune cookies for today.  Please note that I haven't
  12. read monday's contributions yet.
  13.  
  14. -----
  15.  
  16. waldi:
  17.  
  18. > What about a more general file, say GEM-APPL.SYS, which could/would
  19. > contain more than shortcuts? I think there's much more config stuff
  20. > that could be shared by applications.
  21.  
  22. I spent some time thinking about the SHORTCUT.INF file and independently
  23. came up with the same thoughts.
  24.  
  25. My experimental syntax comprises (the number of items NOT being fixed,
  26. though!)
  27.  
  28.    1. application name or empty string.
  29.    2. widget or window class user interface action is valid in
  30.    3. what kind of action (key, button, mouse-in, mouse-out etc.)
  31.       (can be endlessly extended,  as can 2.)
  32.    4. key combination
  33.  
  34. Those four values mapped to an action.  This is better than mapping an
  35. action to a key shortcut as in the above order,  sorting the file will
  36. be a good way of spotting clashes (i.e. it would be hard to attach the
  37. same key to different actions).
  38.  
  39. Example DEFAULTS.INF (preferred to DEFAULT.SYS as 'SYS' denotes a file
  40. which is read by something system-specific,  not by each application)
  41.  
  42. #
  43. #  general defaults
  44. #
  45. **key*sh-ctl-a:                        select-all
  46. *editable-field*button*right-click:    paste
  47. *dialog*key*return:                    ok
  48. *dialog*key*undo:                      cancel
  49.  
  50. #
  51. #  class specific defaults
  52. #
  53. word-processor**key*ctl-i:             italic-mode
  54. word-processor**key*ctl-b:             boldface-mode
  55.  
  56. #
  57. #  application specific defaults
  58. #
  59. edith*window*key*num-0:                iconify
  60. edith*icon*key*num-0:                  open-icon
  61.  
  62. -------
  63.  
  64. andre's proposal.
  65.  
  66. I'll be  straight.  I  don't like  it at  all.  Having  code numbers  is
  67. trouble, as someone will need  to keep track of  the codes.  It is  much
  68. better to prefix special new codes with the name of the application  (as
  69. suggested above) in order to make the standard much more freely useable.
  70. We simply add the clause that if  field number 1 is not either empty  or
  71. equal to the name  of your application or  your application class,   you
  72. must ignore it.   (Precisely as  in .Xdefaults  plus the  extra bit  for
  73. application classes.)
  74.  
  75. Apart from that,  the format suggested above is easier to process.
  76.  
  77. (andre:)
  78.  
  79. > Modifiers: ASCII 1 (up-arrow) for Shift. ^ for Control. ASCII 7 for Alt.
  80. > Modifiers should be displayed in the above order. Alt-Control combinations 
  81. > should be avoided wherever possible.
  82.  
  83. ASCII 1 and ASCII 7 in an ASCII text file are a bad idea.  They are  not
  84. printable characters,   and will  cause  trouble in  e.g. VI or  on  the
  85. printer.
  86.  
  87. (andre:)
  88.  
  89. > To  help  alleviate   this  problem, application-specific   shortcuts
  90. > (e.g. DTP, MIDI,  Database, etc) will have ranges of numbers assigned
  91. > for their use only, which all other types of program should ignore. I
  92. > propose   assigning   blocks   of   1000   codes   (e.g. 0-999    for
  93. > defaults, 1000-1999 for DTP, etc). This should allow more than enough
  94. > entries, and make  the  divisions  more obvious  when  examining  the
  95. > file. We need to decide on useful categories, but this could be  done
  96. > later in the standard and need not hold up the basic default system.
  97.  
  98. A very 'Atari' kind of  proposal,  in the bad  sense of the word.   This
  99. needs more thinking.
  100.  
  101. -------
  102.  
  103. darryl:
  104.  
  105. > personally I like the idear of a keyboard definition file.
  106. > But to maintain a close standard, I reckon we should follow the general
  107. > idear used by WINX, ie have a global setting ( the standard defined by this
  108. > mail list ) and individual program overrides. This would encourage people
  109. > to follow the standard as much as possible.
  110.  
  111. I agree,  the classes bit is a bit fishy.  The WINX solution is water-proof
  112. (though perhaps not bullet-proof.  Tim? :-)
  113.  
  114. -------
  115.  
  116. andre:
  117.  
  118. > Yep. The basic default standard should be defined here fairly soon,
  119. > by the sound of things, as there seems to be general (well, with one
  120. > exception :-) ) agreement on keyboard shortcuts.
  121.  
  122. Actually,  there are large parts of  the current proposal I don't  agree
  123. with.  (I prefer Ofir's first one).  But  I don't care as I have all  my
  124. hopes set on the DEFAULTS.INF files and  once that is there,  I no  more
  125. need to worry anyway!
  126.  
  127.  
  128. -------
  129.  
  130. michel:
  131.  
  132. >      In another message today, one of the people on the list suggested that
  133. > the help key (when combined with the SHIFT key) should enter a context
  134. > sensitive online help mode.  This is a good idea, but since not every
  135. > programmer is willing to take the time or effort of writing such a
  136. > utility, I think that the idea would ultimately die.  This does not have
  137. > to happen, though, because there is already a utility in existance that
  138. > allows programs to (transparently) implement context sensitive online
  139. > help.  The utility is called ST-Guide.  It can be used as an accessory (it
  140. > is very small) or a program.  Once your online help is written (which
  141. > is very easy to do) you can control ST-Guide with a simple appl_write()
  142. > system call, causing it to start at any index within the HyperText file.
  143.  
  144. Just in case you  might find it interesting,   future versions of  Edith
  145. will have a similar feature.  Edith will read MANPATH for WHATIS  files,
  146. and use  the  information  in  those files  to  INTELLIGENTLY  derive  a
  147. hypertext based click-and-browse manual page system.  The big difference
  148. is it will work with plain ASCII files (with special meaning attached to
  149. phrases in  boldface,   Esc  p, q),  i.e. no  need  to  write  dedicated
  150. hypertext files.
  151.  
  152. Access will also provided by  Gemini command line message  (VA_START) in
  153. the accessory version.  Perhaps it would be possible to adopt ST-Guide's
  154. message format?  (what is its format?)
  155.  
  156. >      Anyway, this is just an idea.  Does anyone have any comments or
  157. > reasons why this is a bad idea?
  158.  
  159. Not at all! It  would be a way  to move all your  help files to the  f:\
  160. disk for example.
  161.  
  162. --------
  163.  
  164.  
  165.  
  166.  
  167. -- 
  168. Annius V. Groenink | E-mail: avg@cwi.nl      |  Private & ZFC:
  169. CWI, Kruislaan 413 | Room:   M233            |  P.O. Box 12079
  170. 1098 SJ Amsterdam  | Ext:    4077            |  NL 1100 AB Amsterdam 
  171. Netherland         | Phone:  +31 20 592 4077 |  Phone: +31 20 695 9901
  172.